Container Networking

Introduction

Container networking determines how workloads talk to each other, the host, and the rest of the network. In Docker environments, understanding bridge networks, published ports, and special drivers is essential for secure and predictable service deployment.

Purpose

This document explains how container networking works so you can:

• Choose the right network mode for a workload
• Avoid unnecessary host exposure
• Troubleshoot service discovery and connectivity problems
• Design cleaner multi-service stacks

Architecture Overview

Docker commonly uses these networking approaches:

• Default bridge: basic isolated network for containers on one host
• User-defined bridge: preferred for most application stacks because it adds built-in DNS and cleaner isolation
• Host network: container shares the host network namespace
• Macvlan or ipvlan: container appears directly on the physical network
• Overlay: multi-host networking for orchestrated environments such as Swarm

Network Modes

User-defined bridge

This is the normal choice for single-host multi-container applications. Containers on the same network can resolve each other by service or container name.

Example:

docker network create app-net
docker run -d --name db --network app-net postgres:16
docker run -d --name app --network app-net ghcr.io/example/app:1.2.3

Published ports

Publishing a port maps traffic from the host into the container:

docker run -d -p 8080:80 nginx:stable

This exposes a service through the host IP and should be limited to the ports you actually need.

Host networking

Host networking removes network namespace isolation. It can be useful for performance-sensitive agents or software that depends on broadcast-heavy behavior, but it increases the chance of port conflicts and broad host exposure.

Macvlan or ipvlan

These drivers give a container its own presence on the LAN. They can be useful for software that needs direct network identity, but they also bypass some of the simplicity and isolation of bridge networking.

Configuration Example

Compose network example:

services:
  reverse-proxy:
    image: caddy:2
    ports:
      - "80:80"
      - "443:443"
    networks:
      - edge
 
  app:
    image: ghcr.io/example/app:1.2.3
    networks:
      - edge
      - backend
 
  db:
    image: postgres:16
    networks:
      - backend
 
networks:
  edge:
  backend:
    internal: true

In this pattern, the database is not reachable directly from the host or external clients.

Troubleshooting Tips

Container can reach the internet but not another container

• Verify both containers are attached to the same user-defined network
• Use container or service names rather than host loopback addresses

Service is reachable internally but not from another host

• Confirm the port is published on the host
• Check host firewall rules and upstream routing

Random connectivity issues after custom network changes

• Inspect network configuration with docker network inspect <name>
• Check for overlapping subnets between Docker networks and the physical LAN
• Restart affected containers after major network topology changes

Best Practices

• Use user-defined bridge networks instead of the legacy default bridge where possible
• Publish only reverse proxy or explicitly required service ports
• Keep databases and internal backends on private internal networks
• Avoid network_mode: host unless there is a clear technical reason
• Document custom subnets to avoid conflicts with VPN and LAN address plans

References

• Docker: Bridge network driver
• Docker: Networking overview
• Docker: Published ports